1. Field of the Invention
The present invention relates to a connecting method and a connecting apparatus.
2. Description of the Related Art
There are various techniques for combining software components (hereinafter simply referred to as components) to build an application.
One such technique is Service Component Architecture, the specifications of which have been developed by the Open SOA Collaboration. SCA is characterized in that interfaces of components are simplified as services, references, and properties to facilitate combination of components in different languages and combination of various communication protocols. Details of the combination specifications are described in SCA Service Component Architecture, Assembly Model Specification Version 1.00, Mar. 15 2007.
The SCA specifications specify that components should be connected with each other by using a definition file written in an XML language. If one component uses another component, these components are connected as defined in a definition file. For the using component, it is not necessary to write code that directly calls functions of the component used.
Therefore, replacing a component used in an application with another component does not require rewriting code, if interfaces of both components match each other. This is an advantage of using the SCA technique.
Besides SCA, conventional techniques to replace a component or to verify compatibility between components to be connected, in connecting components to build an application, include the following.
In an exemplary technique, information about connected components is managed and updated on an application basis. On the occurrence of a trouble or at the time of automatic component switching, the version of a component to be switched is determined from the component information. Thus, the version of the component connected in the application is switched. See Japanese Patent Laid-Open No. 2008-108155, for example.
In another technique, based on information about combination between each developed program component in software and based on component attribute information, a specific developed program component forming a part of the developed software is replaced with a new developed program component while the structure of the software is maintained. See Japanese Patent Laid-Open No. 2002-366356, for example.
In a further technique, based on component invocation information extracted by a monitor that monitors component invocations, consistency between a component invocation and an invoked component is verified. See US 2004/0268312, for example.
The SCA characteristic of the easy component replacement is preferable. However, according to the SCA specifications, the content of a definition file must be determined when an application is build, because the definition file is part of the application. That is, to replace a component, the definition file must be modified. This means rebuilding the application is needed to replace a component. Thus, in SCA, a component can be replaced at the time of developing an application but not at the time of running the application.
It is desirable to enhance the flexibility of component replacement as much as possible. Even if components have the same interfaces, many other component characteristics are conceivable, such as performance, resources used, scalability, and availability. Accordingly, many components may be provided depending on desired characteristics. In such a situation, there may be a need for component replacement.
However, component replacement cannot be highly flexible if it requires redeveloping an application. If an application is installed in various devices and it is desired to vary its components from device to device, redeveloping the application for each device would involve an excessively high development cost.
Meanwhile, another situation exists in which component replacement is desired, as follows.
Many network services are provided today. Services that were unavailable are often realized by coordination of devices with network services. Here, consider a situation in which new network services are provided. The high frequency at which new network services are created and provided is incomparable with the frequency at which software in devices is updated. Therefore, it can always happen that network services are updated and improved while device software remains not updated.
In such a case, it has conventionally been difficult to coordinate a device with network services developed after the shipment of the device. Some devices are provided with a firmware update function, with which the devices may be coordinated with new network services. However, firmware update imposes load on a user, and it also involves a low degree of freedom of software modification from aspects such as the ROM capacity. Moreover, as in the above-described case, firmware update also requires development tasks.